Conventional mechanisms for delivering web content data such as HTML pages or images to a client machine for viewing involve pulling the web content data (e.g., HTML pages, images, or script) from a web server when they are needed for display on the screen of the client machine. For the viewing experience of the client, this can result in components of the web content data not being available at the correct time (e.g., an image not yet completely downloaded at a time prescribed by the content author for display). Moreover, requests for such web content data come in bursts, resulting in spikes in network bandwidth demand when such data is being delivered over a network.
Furthermore, such conventional pull-down mechanisms for web presentations lack synchronization and timing between multiple components of the presentation such as audio, video, and images. Synchronization and timing between multiple components of the presentation are very difficult and present many authoring, timing, and delivery issues. As an example, web content data is delivered through a web server whereas audio and video content is delivered in one or more separate streams through a separate streaming server. As a result, the content author would have to invest a substantial amount of time and effort to present the various types of content together in a synchronized manner to the client machine. As another examples, the conventional pull-down mechanisms generally allocate the fullest server bandwidth available for the downloading or pulling of web content data. As a result, there is no idle bandwidth available for the delivery of audio and video data, and audio and video data may not be delivered on time for synchronous playback with web content data.
Delivering web content data in this conventional mechanism as a “real time” or “live” presentation (i.e., as a presentation occurs) can be especially problematic. In a typical live presentation of web content data such as slides and images, the web content data either need to be delivered ahead before the live presentation begins or are pulled from the web server as the live presentation is being conducted. In such cases, every flip or trigger of the web content data can cause numerous pulling requests or hits to the web server, thus requiring the web server to have higher bandwidth capacity. Therefore, there is a need for delivering web content data in a single multicast stream bandwidth that is managed throughout its delivery and with lower bandwidth usage and costs. Moreover, there is a need for a tool that enables a content author to synchronously present web content data to a client.
In the past, some proprietary implementations provided split-trigger mechanisms that trigger web content data into different frames within an HTML page to achieve the appearance of streamed multimedia delivery. Nevertheless, such implementations may still cause sudden pulling requests that result in higher aggregate bandwidth and incoherence between multiple components of a presentation during seeking (e.g., skip, pause, fast forward, and fast rewind) operations. Other proprietary implementations such as HTML+TIME, even though provided synchronization between multiple components of a presentation, did not support streamed multimedia delivery and dynamic insertion of web content data for “real time” or “live” presentations. Furthermore, enhanced television-programming implementations such as ATVEF, even though provided streamed multimedia delivery and tools for authoring live presentations, did not provide mechanisms to avoid data loss over lossy transport. In addition, these enhanced television-programming implementations did not allow seeking capabilities that enhance the overall viewing experience of a client.
Some other streaming techniques have supported partial synchronization between multiple pieces of media. For example, some proprietary implementations such as SMIL have streamed text and images synchronized with audio and video. However, there is a need for an implementation that supports streaming of web content data such as HTML pages. Furthermore, these prior streaming techniques did not provide for a single stream or single file implementation that allows scalability and smooth synchronization between multiple components. For example, certain proprietary steaming techniques delivered image data in one stream, text in another stream, audio and video data in yet other separate streams, and then attempted to synchronize all these data on a client machine. Such implementations did not provide effective synchronization and smooth delivery.
For these reasons, streaming web content data in a single managed stream or single file implementation via a single media server is needed to address one or more of these and other disadvantages.